Giao tiếp Micro-Frontend ở Frontend: Event Bus và Truyền Tin Nhắn

Trong phát triển web hiện đại, kiến trúc micro-frontend đã nổi lên như một giải pháp mạnh mẽ để xây dựng các ứng dụng có thể mở rộng và dễ bảo trì. Bằng cách chia nhỏ một monolith frontend lớn thành các đơn vị nhỏ hơn, độc lập, các nhóm có thể làm việc tự chủ, triển khai độc lập và áp dụng các công nghệ khác nhau cho mỗi micro-frontend. Tuy nhiên, bản chất phân tán này lại mang đến một thách thức mới: làm thế nào để tạo điều kiện giao tiếp giữa các thành phần độc lập này. Đây là lúc các kỹ thuật event bus và truyền tin nhắn phát huy tác dụng.

Micro-Frontends là gì?

Trước khi đi sâu vào các chiến lược giao tiếp, chúng ta hãy định nghĩa micro-frontends là gì. Về cơ bản, micro-frontends là các ứng dụng frontend có thể triển khai và bảo trì độc lập, thường được xây dựng bởi các nhóm khác nhau. Chúng có thể sử dụng các công nghệ khác nhau (ví dụ: React, Angular, Vue.js) và được kết hợp với nhau tại thời điểm chạy, thời điểm xây dựng, hoặc thậm chí là thời điểm tương tác của người dùng.

Các đặc điểm chính của micro-frontends bao gồm:

• Khả năng triển khai độc lập: Mỗi micro-frontend có thể được triển khai mà không ảnh hưởng đến các phần khác của ứng dụng.
• Không phụ thuộc công nghệ: Các micro-frontend khác nhau có thể được xây dựng bằng các công nghệ khác nhau.
• Các nhóm tự chủ: Các nhóm khác nhau có thể sở hữu và phát triển các micro-frontend khác nhau.
• Cô lập mã nguồn: Các thay đổi trong một micro-frontend không được làm hỏng các micro-frontend khác.

Sự cần thiết của việc giao tiếp giữa các Micro-Frontend

Mặc dù tính độc lập là một lợi thế chính của micro-frontends, chúng thường cần giao tiếp với nhau. Việc giao tiếp này có thể vì nhiều lý do khác nhau, chẳng hạn như:

• Chia sẻ dữ liệu: Truyền dữ liệu giữa các micro-frontend (ví dụ: thông tin hồ sơ người dùng, chi tiết sản phẩm).
• Kích hoạt hành động: Một micro-frontend có thể cần kích hoạt một hành động ở một micro-frontend khác (ví dụ: cập nhật giỏ hàng, hiển thị thông báo).
• Đồng bộ hóa trạng thái: Duy trì trạng thái nhất quán trên nhiều micro-frontend (ví dụ: trạng thái xác thực, sở thích của người dùng).
• Điều hướng và định tuyến: Phối hợp điều hướng giữa các phần khác nhau của ứng dụng, có thể được xử lý bởi các micro-frontend khác nhau.

Nếu không có một chiến lược giao tiếp được xác định rõ ràng, các micro-frontend có thể trở thành các silo bị cô lập, cản trở trải nghiệm người dùng và làm cho toàn bộ ứng dụng khó quản lý. Do đó, việc thiết lập các cơ chế đáng tin cậy và hiệu quả để giao tiếp giữa các micro-frontend là rất quan trọng.

Các chiến lược giao tiếp: Event Bus và Truyền Tin Nhắn

Có một số mẫu giao tiếp có thể được sử dụng trong kiến trúc micro-frontend. Bài đăng này tập trung vào hai phương pháp được sử dụng rộng rãi: Event Bus và Truyền Tin Nhắn.

1. Event Bus

Mô hình Event Bus là một cơ chế publish-subscribe cho phép các micro-frontend giao tiếp mà không phụ thuộc trực tiếp vào nhau. Trong mô hình này, các micro-frontend phát hành (publish) các sự kiện đến một event bus trung tâm, và các micro-frontend khác đăng ký (subscribe) vào các sự kiện cụ thể. Khi một sự kiện được phát hành, tất cả các subscriber sẽ nhận được một thông báo.

Cách hoạt động:

1. Định nghĩa sự kiện: Xác định một tập hợp các sự kiện mà các micro-frontend có thể phát hành và đăng ký. Các sự kiện này nên có cấu trúc dữ liệu (payloads) được xác định rõ ràng.
2. Triển khai Event Bus: Triển khai một event bus trung tâm. Đây có thể là một đối tượng JavaScript đơn giản hoặc một thư viện phức tạp hơn như Mitt, rfdc, hoặc một triển khai tùy chỉnh.
3. Phát hành sự kiện: Các micro-frontend phát hành sự kiện đến event bus khi có một số hành động nhất định xảy ra.
4. Đăng ký sự kiện: Các micro-frontend đăng ký các sự kiện mà chúng quan tâm. Khi một sự kiện được phát hành, event bus sẽ thông báo cho các subscriber, và chúng có thể xử lý sự kiện tương ứng.

Ví dụ (sử dụng Mitt):

            
// Create an event bus
import mitt from 'mitt';
const emitter = mitt();

// Micro-frontend A (Publisher)
function publishProductAdded(product) {
  emitter.emit('product:added', product);
}

// Micro-frontend B (Subscriber)
function handleProductAdded(product) {
  console.log('Product added:', product);
  // Update shopping cart, display notification, etc.
}

emitter.on('product:added', handleProductAdded);

// Usage in Micro-frontend A:
publishProductAdded({ id: 123, name: 'Example Product', price: 19.99 });

            

              
                Copy
              
            
          

Ưu điểm của Event Bus:

• Khớp nối lỏng lẻo (Loose Coupling): Các micro-frontend không cần biết về nhau. Chúng chỉ tương tác với event bus.
• Khả năng mở rộng: Các micro-frontend mới có thể được thêm vào một cách dễ dàng mà không ảnh hưởng đến những cái hiện có.
• Tính linh hoạt: Các micro-frontend có thể đăng ký và hủy đăng ký các sự kiện một cách linh hoạt khi cần thiết.

Nhược điểm của Event Bus:

• Nguy cơ xung đột sự kiện: Nếu các sự kiện không được định nghĩa rõ ràng, có nguy cơ xung đột tên. Việc thực hiện một quy ước đặt tên rõ ràng và lược đồ sự kiện là rất quan trọng.
• Độ phức tạp khi gỡ lỗi: Việc theo dõi luồng sự kiện có thể khó khăn, đặc biệt là trong các ứng dụng lớn. Cân nhắc sử dụng các công cụ ghi log hoặc gỡ lỗi để theo dõi các sự kiện.
• Chi phí hiệu năng: Việc phát hành sự kiện quá nhiều có thể ảnh hưởng đến hiệu suất. Tối ưu hóa tần suất sự kiện và kích thước payload.
• Không đảm bảo việc gửi nhận: Các sự kiện có thể bị bỏ lỡ nếu các subscriber không lắng nghe tại thời điểm phát hành.

2. Truyền Tin Nhắn (Message Passing)

Truyền Tin Nhắn liên quan đến việc giao tiếp trực tiếp giữa các micro-frontend bằng cách sử dụng các kỹ thuật như `window.postMessage`. Điều này cho phép một micro-frontend gửi một tin nhắn đến một micro-frontend khác, nhắm mục tiêu một origin cụ thể (tên miền hoặc tên miền phụ).

Cách hoạt động:

1. Định nghĩa tin nhắn: Xác định cấu trúc của các tin nhắn mà các micro-frontend sẽ trao đổi. Mỗi tin nhắn nên có thuộc tính `type` để xác định mục đích của tin nhắn và thuộc tính `payload` chứa dữ liệu.
2. Gửi tin nhắn: Một micro-frontend gửi tin nhắn đến một micro-frontend khác bằng `window.postMessage`. Tin nhắn bao gồm loại tin nhắn, payload và origin mục tiêu.
3. Nhận tin nhắn: Micro-frontend nhận sẽ lắng nghe các sự kiện `message` trên đối tượng `window`. Khi nhận được một tin nhắn, nó sẽ kiểm tra origin và loại tin nhắn để xác định cách xử lý.

Ví dụ:

            
// Micro-frontend A (Sender)
function sendMessageToB(message) {
  const targetOrigin = 'https://microfrontend-b.example.com';
  window.postMessage(message, targetOrigin);
}

// Example message:
const message = {
  type: 'user:updated',
  payload: { id: 1, name: 'John Doe' },
};

// Send the message
sendMessageToB(message);

// Micro-frontend B (Receiver)
window.addEventListener('message', (event) => {
  // Validate the origin to prevent security vulnerabilities
  if (event.origin !== 'https://microfrontend-a.example.com') {
    return;
  }

  const message = event.data;

  if (message.type === 'user:updated') {
    console.log('User updated:', message.payload);
    // Update user profile, display notification, etc.
  }
});

            

              
                Copy
              
            
          

Ưu điểm của Truyền Tin Nhắn:

• Giao tiếp trực tiếp: Cung cấp một kênh trực tiếp giữa các micro-frontend, có thể hiệu quả hơn cho một số trường hợp sử dụng nhất định.
• Tin nhắn có mục tiêu: Tin nhắn được gửi đến một origin cụ thể, giảm nguy cơ có người nhận ngoài ý muốn.
• Triển khai đơn giản: Tương đối dễ thực hiện bằng cách sử dụng các API trình duyệt tích hợp sẵn.

Nhược điểm của Truyền Tin Nhắn:

• Khớp nối chặt chẽ (Tight Coupling): Các micro-frontend cần biết origin của micro-frontend khác mà chúng đang giao tiếp.
• Cân nhắc về bảo mật: Việc xác thực origin của các tin nhắn đến là rất quan trọng để ngăn chặn các lỗ hổng kịch bản chéo trang (XSS).
• Phức tạp trong các kịch bản phức tạp: Việc quản lý nhiều kênh tin nhắn có thể trở nên phức tạp khi số lượng micro-frontend tăng lên.
• Xử lý lỗi: Có thể khó xử lý lỗi và đảm bảo việc gửi tin nhắn đáng tin cậy hơn so với các hệ thống nhắn tin mạnh mẽ hơn.

Chọn Chiến lược Giao tiếp Phù hợp

Sự lựa chọn giữa Event Bus và Truyền Tin Nhắn phụ thuộc vào các yêu cầu cụ thể của ứng dụng của bạn. Dưới đây là một so sánh để giúp bạn quyết định:

Hãy cân nhắc các yếu tố sau khi đưa ra quyết định của bạn:

• Mức độ khớp nối: Nếu bạn cần các micro-frontend có khớp nối lỏng, Event Bus là một lựa chọn tốt hơn. Nếu bạn cần giao tiếp trực tiếp giữa các micro-frontend cụ thể, Truyền Tin Nhắn có thể phù hợp hơn.
• Yêu cầu về khả năng mở rộng: Nếu bạn dự đoán sẽ có một số lượng lớn các micro-frontend, Event Bus thường có khả năng mở rộng tốt hơn.
• Cân nhắc về bảo mật: Cả hai phương pháp đều yêu cầu cân nhắc bảo mật cẩn thận. Đảm bảo định nghĩa sự kiện và xác thực origin đúng cách để ngăn chặn các lỗ hổng.
• Mức độ chấp nhận sự phức tạp: Cân nhắc sự phức tạp của việc triển khai và bảo trì mỗi phương pháp. Bắt đầu với giải pháp đơn giản nhất đáp ứng nhu cầu của bạn.

Các Thực hành Tốt nhất cho Giao tiếp Micro-Frontend

Bất kể bạn chọn chiến lược giao tiếp nào, việc tuân theo các thực hành tốt nhất sau đây sẽ giúp đảm bảo một kiến trúc micro-frontend mạnh mẽ và dễ bảo trì:

• Định nghĩa Giao thức Giao tiếp Rõ ràng: Thiết lập một giao thức giao tiếp rõ ràng và được tài liệu hóa tốt để định nghĩa cấu trúc của các sự kiện hoặc tin nhắn. Điều này sẽ giúp đảm bảo tính nhất quán và ngăn ngừa lỗi.
• Sử dụng Phiên bản (Versioning): Đánh phiên bản cho các sự kiện hoặc tin nhắn của bạn để đảm bảo tính tương thích khi các micro-frontend của bạn phát triển. Điều này cho phép bạn giới thiệu các thay đổi mà không làm hỏng các tích hợp hiện có.
• Triển khai Xử lý Lỗi: Triển khai các cơ chế xử lý lỗi mạnh mẽ để xử lý các sự cố giao tiếp một cách duyên dáng. Điều này bao gồm ghi lại lỗi, thử lại các lần thất bại và cung cấp phản hồi cho người dùng.
• Giám sát Giao tiếp: Giám sát giao tiếp giữa các micro-frontend để xác định các điểm nghẽn hiệu suất và các vấn đề tiềm ẩn. Sử dụng ghi log và các số liệu để theo dõi tần suất, độ trễ và tỷ lệ lỗi của sự kiện hoặc tin nhắn.
• Ưu tiên Bảo mật: Luôn ưu tiên bảo mật khi triển khai giao tiếp micro-frontend. Xác thực origin của các tin nhắn đến, làm sạch dữ liệu và sử dụng các kênh giao tiếp an toàn (ví dụ: HTTPS).
• Tài liệu hóa Mọi thứ: Tài liệu hóa kỹ lưỡng kiến trúc micro-frontend của bạn, bao gồm các giao thức giao tiếp, lược đồ sự kiện và định dạng tin nhắn. Điều này sẽ giúp đảm bảo rằng nhóm của bạn có thể hiểu và bảo trì hệ thống theo thời gian.

Các Chiến lược Giao tiếp Thay thế

Mặc dù Event Bus và Truyền Tin Nhắn là phổ biến, đây là các phương pháp khác cho giao tiếp micro-frontend:

• Quản lý Trạng thái Chung (ví dụ: Redux, Vuex): Một store trung tâm có thể truy cập bởi tất cả các micro-frontend. Điều này đòi hỏi quản lý cẩn thận để tránh xung đột.
• Web Components: Sử dụng các phần tử HTML tùy chỉnh để đóng gói các micro-frontend và định nghĩa các giao diện rõ ràng.
• Backend cho Frontend (BFF): Mỗi micro-frontend giao tiếp với dịch vụ backend chuyên dụng của riêng nó, sau đó sẽ điều phối giao tiếp.
• Sự kiện Tùy chỉnh (Custom Events): Gửi và lắng nghe các sự kiện tùy chỉnh trên DOM.

Kết luận

Giao tiếp hiệu quả là điều cần thiết cho một kiến trúc micro-frontend thành công. Bằng cách hiểu rõ điểm mạnh và điểm yếu của các chiến lược giao tiếp khác nhau như Event Bus và Truyền Tin Nhắn, bạn có thể chọn phương pháp phù hợp với nhu cầu cụ thể của mình. Hãy nhớ tuân theo các thực hành tốt nhất về bảo mật, xử lý lỗi và tài liệu hóa để đảm bảo một hệ thống mạnh mẽ và dễ bảo trì. Khi bối cảnh micro-frontend tiếp tục phát triển, việc khám phá các mẫu giao tiếp thay thế và cập nhật các xu hướng mới nhất sẽ rất quan trọng để xây dựng các ứng dụng web có thể mở rộng và thích ứng. Hãy xem xét đến khán giả toàn cầu và các điều kiện mạng khác nhau khi thiết kế các mẫu giao tiếp, lựa chọn các phương pháp giảm thiểu việc truyền dữ liệu và tối đa hóa khả năng phục hồi. Triển khai giám sát và cảnh báo để chủ động xác định và giải quyết các vấn đề giao tiếp có thể ảnh hưởng đến trải nghiệm người dùng, đặc biệt là ở các khu vực có cơ sở hạ tầng kém tin cậy hơn.